Maybe in the app's migrations ?

I considered it (and it's still an option), but I think it's not ideal for the user to have to manage the operation.

It is not ideal and so I was hoping there was a way to put it in a base class somewhere.

What was your thinking here? Were these steps copied from another project? Wouldn't the start server / mongocryptd commands fail with a suitable exit code if they didn't start?

POC developed here: https://github.com/aclark4life/test-supercharge-action. The verify steps can probably come out.

I guess we should have a separate job for Atlas 8 so we still test with Atlas 7, although it's useful to keep it like this for now so we can see the modifications.

Do we care about 7 outside of QE? If not, let's just test 8. Still thinking about going the other direction and supporting query, queryPreview, etc. But in this one case I think it's reasonable to cling to non-preview and versions that support query.

Yes. In fact, based on the driver policy, we have to support MongoDB 6 until July 2028. I've argued that since Django 5.2 is supported until April 2028, we could make Django 5.2 the last version to support MongoDB 6. This is similar to Django's version support for its built in databases. In any case, it would be nice to finalize and document a MongoDB version support policy.

OK in that case to remove as much ambiguity as possible, and to support as much MongoDB as we can, how about if we go back to 7 for QE and document rangePreview. I haven't thought about the MongoDB support policy in the context of this project, but what you propose sounds fine. Maybe open a PR to the docs with that policy defined so we can discuss there and merge.

Can we use a variable for 8.0.15 so it's not hardcoded in so many places? (I have to research to answer.) Same for ubuntu2204, probably. This action uses ubuntu-latest which is 24.04 I believe.

Yes, probably via env https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables

Users may wonder why it says 8.0 when the MongoDB documentation says 7.0. Even if we only test with 8 because of the range/rangePreview issue, I think our implementation should work on 7.

True, but I'm still inclined to steer away from Preview and only declare support when a query type makes it out of preview.

Using os.urandom(96) generates a different key each time Python starts which is problematic in a local project, except when running tests. Need to explain this or use a different approach.

There is an admonition about it here: https://django-mongodb-backend--329.org.readthedocs.build/en/329/howto/queryable-encryption/#configuring-the-databases-setting

My point here (as we've discussed) is that it's not appropriate to use a random key that changes each time the web server restarts, a management command, etc. Should we hardcode a particular bytestring that os.urandom(96) generates?

Yes, e.g. https://github.com/mongodb-labs/django-mongodb-cli/blob/284ce655970c9b58149e7469f03fecf3a75882d5/django_mongodb_cli/templates/project_template/project_name/settings/project_name.py#L21 although maybe with line breaks.